home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92jul / udi-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  10KB  |  270 lines

  1. Editor's Note:  Minutes received 7/14
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Tim Berners-Lee/CERN
  7.  
  8. Minutes of the Universal Document Identifiers BOF (UDI)
  9.  
  10. The UDI BOF was held at the 24th IETF in Cambridge, MA, USA on July 14,
  11. 1992.
  12.  
  13. Introduction
  14.  
  15. Tim Berners-Lee opened the BOF with a summary of the terms used in the
  16. discussion to date.  The information one quoted in a reference to an
  17. object could comprise many things, among which were possible one unique
  18. name, (Unique Resource Number, URN was one acronym), and zero or more
  19. addresses (Uniform Resource Locators or URLs) which gave instructions
  20. for retrieving the object.
  21.  
  22. The purpose of the meeting was to formalize a standard string syntax for
  23. URNs and URLs in general, and to define specific syntaxes for addresses
  24. in the namespaces of each of the existing network protocols.  [There was
  25. a discussion on acronyms at various times.  URL was decided upon for an
  26. address, and that is used throughout these minutes for clarity.]  The
  27. result should be a standards track document (requiring a working group,
  28. which should probably be in the Directory Area but could be in
  29. Applications).
  30.  
  31. NOT to be discussed were the differences between names and addresses,
  32. URN schemes (which are not yet well enough defined), the full set of
  33. information to be given in a reference, or IPv7.
  34.  
  35. To be discussed were the overall string syntax, including allowed
  36. characters and escaping systems for unallowed characters, the order of
  37. components (little/big-endian), punctuation characters, as well as the
  38. particular prefix to be used to identify each namespace.
  39.  
  40. Specific schemes should be handled in appendices of the resulting
  41. document, and should include:
  42.  
  43.  
  44.  
  45. Prospero     FTP      WWW       telnet    net man. db?
  46. nntp         WAIS     gopher    finger    X.500
  47.  
  48.  
  49.  
  50. Discussion
  51.  
  52. We need methods of keeping up to date the set of appendices without the
  53. same standards track procedure which applies to the full document.
  54.  
  55. It was pointed out that for WAIS one could imagine a separate name space
  56. for databases and for documents.  If this was taken further, a separate
  57.  
  58.                                    1
  59.  
  60.  
  61.  
  62.  
  63.  
  64. prefix would be used for each type of object.  It was on balance agreed
  65. that this could go too far.  One prefix should be used per protocol, but
  66. it should be made clear how to determine the type of an object from the
  67. URL.
  68.  
  69. Peter Deutsch is concerned that we need a syntax for attaching a URN to
  70. a URL, but accepted that it was not for discussion at the BOF.
  71.  
  72. Cliff Lynch suggests three part structure of name, address, and other
  73. stuff.  Peter Deutsch suggests that the document should talk about what
  74. the addresses aren't, in a section on Scope.  This section could also
  75. provide an example of a complete reference, including other information,
  76. by way of explanation but not recommendation.
  77.  
  78. Tim Berners-Lee had submitted in the background document, the W3
  79. implementation:
  80.  
  81. scheme: ____blah___
  82.  
  83. (the syntax of ____blah___ depending on the value of scheme, within
  84. certain constraints.)  There was no dissent, although he noted that this
  85. is the reverse order from the WAIS proposal.
  86.  
  87. John Curran has concerns about URLs being resolvable in such a way that
  88. any two references to the same URL get the same thing.  (unambiguity).
  89. It was generally felt that the system W3 uses to allow URLs to be
  90. incompletely quoted in context was an application issue and was not
  91. relevant.
  92.  
  93. The issue of what we are identifying came up ``resource locator''?  -- a
  94. scheme for somehow identifying resources.  Perhaps identifying procedure
  95. for locating a resource (Karen Sollins and Cliff Lynch).  Cliff Neumann
  96. suggested Document Access Instructions as an alternative
  97. handle/name/identifier for these addresses.  URL was decided on by an
  98. almost unanimous vote.  (Uniform Resource Locator).
  99.  
  100. Peter Deutsch pointed out that we want to focus on interoperability, not
  101. on longevity.  We ought to be able to hand URLs around in short-term,
  102. but not long-lived.  URLs are not unique (in the sense that one document
  103. may have several).  This should be made clear in the document.
  104.  
  105. The class of object you get back should be predictable (Cliff Lynch).
  106. W3 has a real problem with that, since everything is a ``document'' and
  107. handled in a similar way.  Might get a pointer to a database in a piece
  108. of mail.  The question of whether one gets back a file or a directory
  109. from a FTP URL arose.  Archie really wants to know what it is getting
  110. back.  Within a scheme, should be documented syntax that will clarify
  111. which sort of object will come back.  If we go too far down this track,
  112. we fairly quickly get to full object-oriented world, with fullscale
  113. typing.  Alan Emtage.  suggested that simple enumeration of acceptable
  114. types.  Extensions based on documented new subtypes, based on documented
  115. protocols.
  116.  
  117. A separate issue of whether human or only machine readable.  Previously,
  118.  
  119.                                    2
  120.  
  121.  
  122.  
  123.  
  124.  
  125. included issue of printable.  This is needed because don't have names
  126. now.  Question arose of whether once these addresses exist will be
  127. replaceable with names - will be presented as new functionality, not
  128. replacing existing systems.  Agreement on some way of specifying class
  129. of objects.
  130.  
  131. ``Context'' Prefix
  132.  
  133. IT WAS AGREED that the context, or namespace prefix be the first
  134. (leftmost) part of the URL, and be separated from the rest of the URL by
  135. a colon.
  136.  
  137. The punctuation ``//'' was discussed.  Currently, W3 URLs use ``@'' for
  138. login information.  An extension of server the server hostname can
  139. include a port number in all current schemes.
  140.  
  141. The issue of how to manage additional schemas was discussed.  Each
  142. appendix should be checked out by a particular group within the IESG,
  143. and perhaps should be an ``Expermental Standard,'' rather than simply an
  144. ``informational RFC.'' The document will describe how to write
  145. appendices.
  146.  
  147. Syntax Details
  148.  
  149. The syntax should be human typable (majority agreement).
  150.  
  151. Should one use punctuation, or attribute-value pairs?  Attribute value
  152. pairs get mispelt.  (note x.400 vs.  Internet addresses)
  153.  
  154. It was decided to use a short string with punctuation rather than an
  155. attribute-value pair system.
  156.  
  157. We must specify the terminator (by declaring some characters as illegal
  158. inside a URL).
  159.  
  160. Is a URL nestable?  If one URL can contain another, one needs nestable
  161. begin-end pairs.  (Alan Emtage).  Currently W3 URLs are not nested
  162. visibly although escaping allows URLs to be encapsulated within URLs,
  163. for example by gateways.
  164.  
  165. Allowed characters:  characters should be disallowed if they are needed
  166. as terminators (`''', `;') or are too easily mutialtable by passage
  167. though (for example ASCII/EBCDIC/ASCII) gateways (tilde, backslash).  A
  168. subset of an ISO 7-bit code should be defined, with reference to MIME
  169. work.
  170.  
  171. Future Discussion
  172.  
  173. Mailing lists:  NIR list at McGill will be used by Jill Foster and
  174. George Brett's NIR BOF. ietf-url@merit.edu will be used by this Group.
  175. First of all, we should ask Mike Schwartz whether he is willing to run
  176. all mailing lists on one machine (at least nir and url) in order to cut
  177.  
  178.                                    3
  179.  
  180.  
  181.  
  182.  
  183.  
  184. down on multiple copies opf cross-posted messages.
  185.  
  186. Accomplishments
  187.  
  188. Things which the meeting had brought to light included:
  189.  
  190.  
  191.    o ``File:''  is too broad a description, ``ftp:''  would be better.
  192.      If a given client knows that it can in fact access some FTP sites
  193.      as local files, that is a local client issue.
  194.  
  195.    o Escaping is to be defined.
  196.  
  197.    o Relative naming is a client issue.
  198.  
  199.    o We should look at what we call ``news:''  (``usenet:''?).
  200.  
  201.    o We should we be able to tell what sort of an object we have (eg
  202.      database or document) by simple examination of the URL
  203.  
  204.    o We need a scheme for managing the addition of new schemas (cf
  205.      Directory object definitions).
  206.  
  207.    o The document should be an ``Experimental Standard'' RFC.
  208.  
  209.    o Mailing lists will be defined and a single message sent to cniarch
  210.      to say what is happening.
  211.  
  212.    o The time-frame for the document was:  soon.  Probably in the OSI
  213.      Directory Services Area (Erik Huizer has suggested this).  We need
  214.      a working group if we want to go through the IESG. But in reality,
  215.      if have big applications buying in, then will be a de facto
  216.      standard.
  217.  
  218.  
  219. Final Comments
  220.  
  221. We may need to separate WAIS from Z39.50.  (C Lynch).  We may also need
  222. SQL. Also we should include X-junk:  type extension mechanism for
  223. experimental schemes.
  224.  
  225. These minutes noted on-line by Karen Sollins (Thanks!)  and edited by
  226. Tim Berners-Lee.  They are available as:
  227. URL http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI]_BOF_
  228. Minutes.html
  229.  
  230. Attendees
  231.  
  232. Vikas Aggarwal           aggarwal@nisc.jvnc.net
  233. Harald Alvestrand        Harald.Alvestrand@delab.sintef.no
  234.  
  235.                                    4
  236.  
  237.  
  238.  
  239.  
  240.  
  241. Mark Baushke             mdb@cisco.com
  242. Tim Berners-Lee          timbl@info.cern.ch
  243. George Brett             ghb@jazz.concert.net
  244. Mitchell Charity         mcharity@lcs.mit.edu
  245. Jodi-Ann Chu             jodi@uhunix.uhcc.hawaii.edu
  246. John Curran              jcurran@bbn.com
  247. Richard desJardins       desjardi@boa.gsfc.nasa.gov
  248. Peter Deutsch            peterd@cc.mcgill.ca
  249. Alan Emtage              bajan@cc.mcgill.ca
  250. Jill Foster              jill.foster@newcastle.ac.uk
  251. Ray Freiwirth            5242391@mcimail.com
  252. Jim Fullton              jim_fullton@unc.edu
  253. Martyne Hallgren         martyne@mitchell.cit.cornell.edu
  254. Erik Huizer              huizer@surfnet.nl
  255. Bill Manning             bmanning@rice.edu
  256. Clifford Neuman          bcn@isi.edu
  257. Sam Nicholson            scion@pblx.knox.tn.us
  258. Jon Rochlis              jon@mit.edu
  259. Karen Roubicek           roubicek@faxon.com
  260. Richard Schmalgemeier    rgs@merit.edu
  261. Vincent Sgro             sgro@cs.rutgers.edu
  262. Jane Smith               jds@jazz.concert.net
  263. Karen Sollins            sollins@lcs.mit.edu
  264. Simon Spero              ses@cmns.think.com
  265. Chris Weider             clw@merit.edu
  266.  
  267.  
  268.  
  269.                                    5
  270.